home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0399 / 357 < prev    next >
Internet Message Format  |  1994-08-27  |  3KB
  1. Date: Wed, 8 Jun 1994 00:20:42 -0400 (EDT)
  2. From: Timothy Miller <millert@undergrad.csee.usf.edu>
  3. Subject: Re: Proposal v5
  4. To: gem-list@world.std.com
  5. In-Reply-To: <199406080346.AA239067187@relay2.geis.com>
  6. Message-Id: <Pine.3.87.9406080042.A10748-0100000@grad>
  7. Mime-Version: 1.0
  8. Precedence: bulk
  9.  
  10.  
  11.  
  12. On Wed, 8 Jun 1994 s.sanders2@genie.geis.com wrote:
  13.  
  14. > Reply:  Item #1356720 from GEM-LIST-APPROVAL@WORLD.STD.COM@INET01#
  15. >  
  16. > All:
  17. >  
  18. > Ok, ok, so no one likes the SHIFT-CTRL-C 'Copy to...' :) That's
  19. > fine. I still don't agree that a database or spreadsheet could do an
  20. > append easily or intuitively. I think leaving SHIFT-CTRL-V as 'Paste
  21. > from...' would be useful.
  22.  
  23. Actually, _I_ like 'Copy to...'.  I think there needs to be a key 
  24. combination for 'export block', and that's what this is... unless you 
  25. want something like Ctrl-E or shift-ctrl-E for Export.  In that case, you 
  26. wouldn't need a shift-ctrl-v 'Paste from...' because you'd change the 
  27. terminology to Import (shift-ctrl-I?).
  28.  
  29. Then shift-ctrl-C would be copy-append to clipboard and shift-ctrl-x 
  30. would be cut-append to clipboard.  What would shift-ctrl-v become?  This 
  31. would be for where is it applicable, only.
  32.  
  33. >  
  34. > I think the ClrHome combinations should be changed too as follows:
  35. >  
  36. > ClrHome            - Top of Window
  37. > SHIFT-ClrHome      - Bottom of Window
  38. > CTRL-ClrHome       - Top of Document
  39. > SHIFT-CTRL-ClrHome - Bottom of Document
  40.  
  41. Ah, yes.  We are NOW using some smart thinking.  If something is too easy
  42. to hit, you are careful about it, and do it in a way that doesn't create
  43. extra work for the programmer.  I sure wish this were always the case. 
  44.  
  45. >  
  46. >  
  47. > Tim Miller:
  48. >  
  49. > The structure I defined would define RETURN as 0x000D and CTRL-M as
  50. > 0x004D. Every alphabetic key would be stored in uppercase and you'd
  51. > use the shift parameter to determine which modifier keys were down.
  52. > The only ones that we'd have to standardize a set for would be non
  53. > ASCII printable like F1-F10, Help, Undo, etc.. i.e. ones with a low
  54. > byte of 0x00.
  55.  
  56. Ah!  Now I understand!  It wasn't clear to me before that you were 
  57. suggesting that one REPLACE the key table.  This way, the application has 
  58. complete knowlege of what's going on, including the state of the shift 
  59. keys, independantly of what keys are hit.  This way, using right-shift 
  60. for selecting a block would be easier to implement.
  61.  
  62. The solution _I_ came up with was a bit different.  Since the placement 
  63. of return, enter, backspace, tab, and escape don't change on foreign 
  64. keyboards (to my knowlege), the equivalent ctrl-keys would have the same 
  65. ascii value, but a different scan code.  It's then a simple if not equals 
  66. thing.
  67.  
  68. >  
  69. > Alexander:
  70. >  
  71. > I think it would be prudent in some cases to allow more than one
  72. > equivalent for a function. How this would be implemented would have
  73. > to be decided but I know almost _every_ USA program uses CTRL-SHIFT-S
  74. > and every German one uses CTRL-M. Windows does this a lot. Many
  75. > programs use CTRL-X and CTRL-INSERT for Cut. Only CTRL-X is put in
  76. > the menu. A really smart program could display the equivalent in the
  77. > menu for the country it's compiled for but still accept both.
  78. >  
  79. > -Scott @ SDS
  80. >  
  81. > 
  82. I agree with the above, but don't get messy about it.
  83.  
  84.  
  85.